There seems to be some question around here concerning where standard OK and Cancel buttons should be in a dialog. Assume I am designing a dialog that that has the OK button as the default action. At the Developer's conference, I got the feeling you prefer that we place this OK in the lower RIGHT Corner. Correct? Now were does the Cancel button go? Just to the left of to the Ok or at the bottom LEFT corner of the dialog?
I realize that the guidelines aren't very clear on button layout in dialog boxes. We're trying to remedy this with a Human Interface Tech note on this. We hope to address most of your questions in greater detail there but in the mean time let me give you the 15 second synopsis.
There are two design guidelines we'd like to stress in dialog box layout. The first is that the eye (at least for western readers) tends to flow from the upper left to the lower right of a dialog box. This stresses putting the initial impression you want to convey at the top left; the icons in the alert boxes are a good example here. The lower right should be the "ultimate" buttons you need to push, usually OK(or some more descriptive action) or Cancel. This guideline eases identification and use of dialog boxes.
The other guideline is consistent placement of these buttons. The general rule is that the OK (or equivalent "Action" button) should be in the lower right with the Cancel button to its left. The default button can be anywhere, it is secondary to the placement of the buttons. This rule keeps the Action and Cancel buttons consistently placed, otherwise, depending on the default, the buttons would keep changing places. Please note that this rule works well for Alerts and simple dialogs. It is possible for a dialog with multiple action buttons to look better with the Cancel button placed slightly differently or even for the buttons to be placed vertically on the right side of the dialog.
One last little note, please be sure to 1) map Command-period and escape to the Cancel button and 2) hilite the button when these keys are hit.
All of our FrameGrabber software shipping with our FrameGrabber boards write PICT2 files as well as TIFF. And like many Macintosh applications we extend the standard File Save As dialog with radio buttons for the user to select which type of file to create.
Question: Is PICT2 a term for the developer? i.e. Should the choice for users read "PICT" or "PICT2" ?
Users should see the term 'PICT', not the term 'PICT2'. The version 2 PICT definition is backwardly compatible (as much as possible), so there's no reason a user should have to distinguish between version 1 PICTs and version 2 PICTs. Thanks for writing!
Question: Has the standard key press for closing (cancelling) a dialog been expanded to include the escape and/or clear keys in addition to command-period?
Both command-period and escape are valid keyboard equivalents to the Cancel button. This actually has been in the the HI Guidelines (p 99) since early '88. Clear however, has never been intended to mean Cancel.
Please be sure, whatever you do, to hilite any button before closing the dialog.
I have an interesting problem concerning the use of color and selecting text. A feature I would like to add to the current application I'm working on would include the ability to change the background color of any text range according to user preference. Different sections of a document could therefore have different colors, which would have nothing to do with the system background color. Here is my dilema, when I select text, according to the human interface guidelines, the program sets the selection to the background color, but since the background color is set, no selection is shown. If I invert the color, then the user is able to see the selection, but the inverted color has nothing to do with the user choice.
You have the same problem in the color finder when you choose color icons. The user can see that an icon is selected, but the colors are changed by some RGB inversion. Since I'm allowing the user to apply coloring to the background, this seems a real violation of Macintosh simplicity and elegance to not show the true choice until after the user deselects the selection. (Besides, inverted color can really look ugly.)
I would appreciate any solutions you might have to this problem.
Ah, good old color selection problems. The first thing I would like to point out is that the color finder INIT was written by someone who is working at Apple, but the INIT itself is not an Apple product in any way. I say this only to emphasize the point that the color icon support in System 7.0 has nothing to do with the color finder INIT. We have not decided how to show selection on multicolored icons in System 7.0 but one thing we do know is that it will NOT be done by color inversion as in the color finder INIT. Our fallback choice if we can't come up with anything better is to show the inverted B&W version of the same icon (thus even further encouraging color icon designers to colorize, rather than redesign, their B&W icons). But what we really hope to do is something in which each color in the selected icon goes to a different but related color -- for instance, all the colors get brighter, or all the colors get darker. We're currently experimenting with how this looks given the constraint that we want to stick to the system pallette.
So with this in mind, I might suggest that you look into analogous solutions for your problem. For instance, one solution might be to use the system highlight color except when it's too close to the local background color, and in that case use black (if the local bg color is light) or white (if the local bg color is dark) instead. Another solution would be to use the system highlight color only when the bg is black or white, and to use a brighter (or darker) shade of the bg color in all other cases.
Another approach would be to consider ways in which the system highlight color could always be used while still preserving the ability to see the selection. Perhaps adding a two pixel border of white or black around the selection would work. This may be horribly ugly though.
I think it's about time to get rid of the "Drive" button in the SFGetFile/SFPutFile dialogs, replacing it with a popup list of volume names (like Ray Lau's SFVol INIT, but with a proper box with drop shadow to indicate it's nature).
I now have 6 volumes online and often have more -- mostly various AFP file servers scattered around as well as "Excellent CD" and "Audio CD 1". It's a royal pain to slowly step through them while the Mac goes off to enumerate directories on file servers you don't care about or on slow CD-ROMs until you get to the right one. And you have to pay close attention, since it's always a surprise to find out which volume is next. Then of course there are the silly alerts that pop up along the way, saying "The Disk is Locked!" when some applications see a CD-ROM and all you were trying to do was get past it to a floppy volume.
Anyways, you get my point (I hope). I don't know how anyone (with more than 2 volumes) gets by without SFVol Init.
Yes, you've got a very good point. That's why we're changing SFPut and Get for 7.0. Now when you click on the standard popup, instead of showing open folders only up to your drive, it will continue one more level "up" and show "The Desktop." Going to this level then shows you all of your drives in the same way your files were displayed, allowing you to click or type select them just like you would files. The name of the current drive will still be visible as it is today.
If you're a real power fiend, the left and right arrows now work to take you forward and backward through your drives if you don't want to use the popup or don't want to use "Command up arrow" to get to the top.
I was recently going over some of the System 7.0 specs and have a few
questions/suggestions...
1) Regarding Alias objects in the new Finder:
Is there going to be a visual distinction between alias objects and original objects? I'm specifically worried about file icons. If file icons will be visually identical, could I strongly suggest that you implement them in such a way that it is obvious to even the casual user which icon is an alias icon and which is an original icon. As one who has been forced to "waste" too much time with end-users just attempting to locate the correct icon, I can assure you that tech support engineers will appreciate a visual distinction very much. A good example might be when attempting to "trash" an icon that is causing a problem...will "trashing" the alias also "trash" the original, or will it just remove the alias?? I'm sure that you have thought through all of this, but I just want to be sure that the new finder isn't going to make tech support any more difficult for either the end-users or he support engineers...
2) I haven't seen any mention of the ability of the finder to consolidate multiple files into one finder icon:
I wonder if you've thought how this might clean up and simplify the Finder interface? For example, many business and database applications make use of multiple files that comprise one set of data for the app. Acius,Chang,Great Plains,Layered, Satori, and many other developers offer applications that handle data in this way. There are at least two problems with having multiple icons that represent one set of related data.
a) Many users attempt to "clean up" their desktop by moving *some* of these related files into separate folders. (trust me!! I speak from experience here...) This either forces the developer to write extra "go find my files" code, or in most cases forces them to refuse to launch until the user "uncleans" their desktop. Neither option is very kind to the user.
b) Users cannot be sure of which icons they are supposed to back up with applications that handle data in this fashion. An example might be our series of accounting software. We have two types of documents: accounting data documents and report template documents. There is no reason that the user needs to back up the “report template” documents, since they generally are not changed after they've been created. But, they absolutely had better back up their accounting data. For our specific app, it would be much more intuitive it the user only saw two document icons, one that was comprised of multiple data documents and one that was comprised of multiple "report templates".
The ability to create file groups under one icon should be something controlled by the programmer, and there should probably be a "power user" feature to allow the user to "look into" a file group (this would be nice, again, for the tech support people). I guess what I'm basically describing is a special type of folder that has an application defined icon and that cannot be opened through simply double clicking.
I guess that's all I've got for now...I would appreciate a reply regarding the
First, aliases. Everyone (well, everyone we care about) agrees that aliases must be visually distinct from non-aliases. But at the same time, it's very important that you can tell at a glance what the alias is an alias of. We combined these two needs in every way we could think of and came up with the following solution: an alias will have the same icon as the original file, and the same name (appended with "alias", but renameable). The visual distinction will be that the names of aliases are italicized. This will be true in the Finder, in the Apple Menu, and in Standard File. So the distinction will be noticeable, but not screamingly obvious. (Of course I should postscript this with "this, like everything else about System 7.0, is subject to last-minute change." I don't think it will change, though.)
Your second subject is more tricky. You would like the Finder to be able to "consolidate multiple files into one Finder icon." When I first read this, I thought "but that's exactly what folders are!" Reading further, I see that you want something that's less user-controllable than folders; for instance, you want to make it hard or impossible to separate related files.
The Finder has always had the approach of "show the users all the files, and let them do what they want." Although there have been some cases, mostly dealing with the System Folder, where this has burned us, for the most part it seemed like the best philosophy for the Finder to take. This has left the question of how much an individual file contains to the application developer.
We are not planning to change this for Finder 7.0, but that doesn't mean you're out of luck. There are two things you could do that would give you (I believe) what you want. The first is, as I've implied, to have your application store all the related pieces together under a single icon in the Finder. Then the user cannot separate these pieces while in the Finder. Your application can do whatever it wants on a double-click, of course, including showing the next level of detail of the bundled pieces. Your application can make it arbitrarily hard to separate the pieces. Perhaps the normal behavior of the application is to save these pieces as one file, but the super-power-user can do something to save each piece separately as an individual file.
I hope this is useful—-please let me know if I haven't adequately addressed your interests.
This message falls into the "I've got an idea" category. I hope that it finds its way into the hands of someone who will appreciate it.
Background:
The macintosh has a pattern for the desktop. On color Macs it can even be in color. To organize folders in a way that makes sense to the user, the Mac lets you move the files arround on the desktop and within the folders. On color systems you can even color the files, folders and programs as desired.
The idea:
Why not allow more of the same. How about being able to select the background pattern/color for the inside of each folder. The user could then more easily recognize an edge of a folder behind other folders by the color or pattern of the small part that is visible. Pushing this concept further why not have a simple drawing ability on the desktop and inside folders. The user could circle a group of files and label them. Or simply draw horizontal or vertical lines inside the folder and move files to one side or the other to make some logical distinction. Just the basics would be enough (oval, rectangle, round rectangle, lines, arcs, text). The tools could be in a menu like HyperCard that is present when the Special menu is present. Maybe make it a tear-off menu. Alternately you could just provide the hooks and allow third party developers to make DAs that could put pictures in the folders PICT.
Your idea for a customizable folder background is an good one and something we've had on our "wishlist" for a while. We'd certainly like to get it into some future release.
I am developing a program that will use one or more floating palettes. It is designed, as all good programs should be, to run happily under Multi-Finder. My questions relate to the interaction between the layers of a Multi-Finder environment and the layers of my own environment. In my layer all palettes float above all documents. The question is what do I do when I am not in my layer (ie. I have been swaped out by Multi-Finder). The prevailing wisdom is that I hide all of my palettes when I am not the frontmost layer. That is I hide the palettes on a suspend event, and re-show them after a resume event. Does this agree with MacInterface's view. For that matter what other rules of Multi-Finder etiquette have been established. The guidelines book is mum on this subject. But with the comming of System 7.0 all programs will have to live in this environment.
Often a user will want to be able to paste into a modal dialog box. A good example is in the search dialog in MPW (although this is certainly not the only example). Here the user will want to be able to paste in a sometimes long and usually complex string. There is no call to use a modeless dialog, since in text editing such an action is very modal. In the case of the MPW dialog the command keys are supported, but otherwise dialog is completely modal. It could be argued that command keys do not in any way violate the "modality" of the dialog. But according to your article the edit menu should be put into the dialog, if you are to support Cut/Copy/Paste/Undo at all. While I think it would be a neat idea, I can also see it cluttering up a lot of dialog boxes. I have seen some programs try to encorporate the editing features via buttons in dialogs (PowerMenus, from Magic Software,for instance in thier CDEV "player"), but this is very clunky and unatatural. Also the edit command keys are probably the best known command keys for most Mac users, and almost always work, shouldn't they also work in modal dialogs. I realize that for modeless dialogs and CDEV's there is DlgCut, DlgCopy and DlgPaste, but what about modal dialogs. Finally, on this subject, some (many) programs support Cut/Copy/Paste/Undo in modal dialogs, but it is erratic, sometimes even in a single program. While I agree that many modal dialogs should become modeless as screen real estate increases, I nonetheless believe many dialogs should or will remain modal (SFGetFile for instance). For these dialogs, and standard on Cut/Copy/Paste/Undo could be used.
First, about your questions on layers with MultiFinder. While the guidelines are annoyingly mum about suspend and resume, we recommend hiding all "unnecessary" windows/pallets on a suspend event. By unnecessary I mean both pallets AND modeless dialogs such as Search/Replace dialogs. This is a new position, one which most developers don't do. This is just one reason why we are in the process of updating the guidelines, to get this information out to everyone. The main reason we suggest this is that in an environment with >2 apps running, window clutter can become quite distracting and as the users focus is the document, all peripheral windows not directly related to the document should politely get out of the way.
About clipboad support in modal dialogs, the standard line here is to allow access to the menu bar from within a modal. Unfortunately this isn't possible without using a filter proc, but it isn't that difficult. The only trick here is that any menus not supported in a dialog should have grey titles. This way you get both command-v (which should still hilite the menu bar by the way) and also standard mouse and menu interaction for the same behavior.
I hope this ansers your questions, please feel free to follow up if not.
I would like to be able to insert a "section title" into a menu as an item, for use in menus which comprise more than one section. You can put the dotted line there to separate the sections, but the purpose of the section may not be obvious from the names of the individual items. I have in mind an item which is not selectable but also not disabled-looking, perhaps a dotted line across the menu with some non-gray text in the center.
I have seen these "menu headers" implemented as permanently dimmed items with sub-items indented a couple of spaces, but this seems visually clumsy, and many people complain of not being able to read gray Chicago.
We've also toyed with this idea but have a couple of concerns. The first was how could we make it obvious that the "sub-title" wasn't an item? By the very definition and subsequent use of menus over the last 6 years, this seems almost impossible.
The other concern was that we aren't solving the "real" problem. The instances here at Apple where an engineer would come to us with this desire to sub-label the menu items, we were able to redesign the menus/app to make everything simpler and more intuitive (these redesigns have NEVER used hierarchical menus). This is of course a case by case process and I don't have any good rules to give you on what you could do.
We certainly agree with you that the dimmed items with indented sub-items is right out but if you really have a case where this would be a big win I'd like to see it.
I just started using FullWrite and discovered their "Menu-Bar-in-a-window" technique. For me as a user, it was a perfect example of Mac-like interface extension: use existing vocabulary to increase power in an easy, intuitive, non-cluttering way. What's your position on this technique?
We've all looked at FullWrite's menu within a window and also think that it was very well done and intuitive. In addition to making this menu bar behave exactly the same and also nicely rounding the corners to look like the "real" menu bar, it's interesting to note what they DIDN'T do:
• There's no "Apple" menu
• There's no File or Edit menu.
• No menu items are duplicated between the main set and the window set.
• The window isn't resizeable, which could hide menus if resized too small.
FullWrite obviously put a lot of work into making sure these menu wouldn't be confusing and it seems to work well.
There is another point to keep in mind. Contrary to certain programmer types with excessive BIOS on the brain, the Mac menu bar has shown to be a suprisingly quick access mechanism. In our internal speed/error testing of various menu strategies, the global menu bar has not only been more accurate, but also faster. This is a suprising result. There has recently been some human factors research outside of Apple confirming this. Their conclusion is that the major advantage to the global menu bar is that on moving the mouse cursor towards the top of the screen it gets "pinned" at the top, preventing any "overshoot." Users unconciously rely on this to "get there fast" and then once there, "find what I need." This isn't an argument against menus in windows, just that they will most likely be more error prone and should be used with caution.
I'm afraid that there is no short term plans to make this available in System 7.0 (we're already up to our ears in features) even though I think it is a promising idea.
If you decide to do something yourself in spite of our lack of help please feel free to drop us a screen shot/prototype for comments.
I am working on an application which always displays multiple text documents. Each document has many options which are set via dialog boxes and saved with the document. My first approach to setting these options was to have an Options menu in the title bar. Unfortunately, every time a different document was selected as the front window, the option settings changed to the ones last set for that document, rather than the options just set. This has been very confusing to users (option pong). To make it clear that each document carries its own set of options, I would like to have an option button somewhere in each document window. Is the title bar OK? Or should I place a popup button in a pane at the top or bottom of the content region? Any rules or suggestion would help.
There are a couple of things that I'm not clear on in your message. At one point you say that "each document has many options which are set via dialog boxes", but later you say that these options were set (in an early version) from an Options menu in the menubar. So I'm uncertain about the nature of these options, and how they are set. I could probably give more specific advice if you clarified the nature of these options a bit more.
That aside, I can still tell you a few things. First, it is in general a bad idea to add anything to the title bar of a document window, for two main reasons. The technical reason is that Apple may at some future time update its standard window definitions, and all apps that used the standard window definition get the update for free, but apps that have altered the title bar do not. (Incidentally, as far as I know altering the appearance of the title bar can only be done by creating a custom WDEF, not a task for the faint-hearted or so my hardcore programmer friends tell me.)
The nontechnical reason why it's bad to add anything to the title bar of a document window is that the standard document window appearance is very ingrained in Mac users' consciousnesses. Any change to it makes your windows "look weird" and could cause users to feel less comfortable about doing the standard window things to your windows. If all apps' window appearances were slightly different, the Mac would lose some of its consistency and users would not be as comfortable as they are now exploring different applications.
So it seems to me that there are two places left for your options button to go (assuming that's the best design -- a little more on this later): at the top of your content region or at the bottom. At the bottom you could have your horizontal scroll bar (assuming you have one of course!) extend not quite all the way to the left, and use the bottom left corner for your button. A fair number of apps put something down there, such as MPW, FullWrite, Word, MacWrite II, etc. Don't do the opposite by putting the button on the lower right corner and shortening the right end of the horizontal scroll bar -- this would look bizarre. If you put the button at the top you could possibly combine it with other document-specific information like the rulers in many word processors.
So finally a bit of unsolicited advice. Again, I don't know enough about your program to say anything concrete, so you can take or leave the philosophical ramblings. "Options" sounds awfully vague -- a lot of times it seems that "options" means "anything the developer couldn't figure out how it logically fit into the application structure." Perhaps there's some way to integrate the information you are presenting as "options" into the rest of your application in a structurally consistent manner. For instance, consider MacDraw. There are lots of items in the menus that change with each document, such as the font, fontsize, and style selected, whether the grid is showing, the pen size and arrow styles, etc. The designers could have taken all of the document-specific information and put it in one place, but they decided that it made more sense spread out over several menus. And although all of these settings may change back and forth when a user switches documents, users don't complain about "options pong" (a great term!) with MacDraw because it makes sense to them. Again, since I have no idea what you're doing I'm obviously not criticizing your design, but I thought I'd throw in my two cents on this matter anyway.
Please let us know if we can be of more help and thanks for writing!
We have a window that is acting as a modeless dialog. It has a List Manager list which allows cells to be edited in a tedit buffer, something like Excel. (No, we are not abusing the managers and building a spreadsheet with the ListManager package.) A <return> or <enter> moves the selection to the next cell. Since this is a dialog to set program parameters, the window includes standard buttons like "Ok" and "Cancel".
Now, what do we do about default buttons? It seems that the OK button should be the default, but the <return> is already being trapped by the tedit-list mechanism. We could get rid of any default. We could assign different meanings to <return> and <enter> (ugh). What is the Mac-Friendly solution?
The user will want to enter lots of values into this list. Mousing on each cell is likely to be painful.
This looks like a good place to roll out a few Mac Interface Principles (MIPs for short). First, modeless dialogs should NEVER have Ok and Cancel. Modeless dialogs by their definition don't need confirmation. Next, the standard way to move between text fields is to use the Tab key (with Shift-Tab reversing direction).
Now to answer your question. Without understanding more about your "cells" its difficult to discuss wheither or not you should use Tab. If you have a compelling reason to use Return, such as your cells indeed behave like spreadsheet cells, then you're still fine as you your dialog is modeless and doesn't need a default button.
If, for the sake of argument your dialog was modal, I would be very suspitious of a design requiring this type of editing facility in a modal dialog. Modal dialogs are best for very specific(even complex) questions. Generalized editing within a modal almost always turns into a very messy interface problem.
Re: Permanently relocating the Trash Can on large screens.
We have had a number of requests from users of large screens about how to permanently relocate the Trash Can up near the disk icon (for easier access). A search with ResEdit reveals no obvious paramaters that can be reset to control Trash Can location. It appears that the location is dynamically calculated at startup time, depending on the screen size. Has anyone written an INIT which allows users to override the Trash Can location? Surely this problem has been identified elsewhere, as increasing numbers of large screen Macs are installed. The rigid definition of locating the Trash Can in the lower right corner of the screen makes the Macintosh User Interface work against 'user friendliness' in the case of large screens.
Any advice anyone can provide would be appreciation.
Yes, you're right. The current Trash Can behavior is a real problem and that if one of the many reasons we are rewriting the Finder. With System 7, the Trash Can location will always be remembered, even across multiple monitors. Unfortunately, there is nothing you can do "fix" the problem for 6.0 systems, the location is hardwired into the code, no attempt is made to save and restore the location.
How do you feel about having dimmed items in a popup on a modal dialog? Does it make more sense to use radio buttons if one of the items must be dimmed based on some other item in the dialog?
About your question on popups with dimmed items. Without more information its difficult to give you a precise answer. My first question is what type of items are in your popup? Another is what kind of structure is there to your dialog to explain the relationships between various radio buttons and the popup items? A screen shot with and without pop ups would go a long way in filling in the details.
There is a generic answer however. Dimming is an oversed interface trick. While it often works it is also often abused. A common problem found in user testing is the user screaming "Why CAN'T I search!!! What's keeping me from using it??" This problem especially crops up when you have a list of only partially related items and you decide to dim just one for a unfortunately very valid software constraint. The user doesn't have the programmers model so it appears to be a very arbitrary action. So the guideline is to go out of YOUR way to put as much structure into your app for the user to understand the relationships. This usually turns into a layout issue, making the items that dim be visible (through radio buttons, checkboxes, etc.) when they become unavailable. An example would be the "Draft" quality for an ImageWriter dimming when you choose Landscape orientation.
Without knowing more, I can't give you good advice. If you have no choice but to bury these items in a pop-up menu, I'd recommend not dimming the item but bringing up an alert explaining why it's not available. This idea can go too far, bringing up an annoying large number of alerts that could drive your users crazy. But if this were the case, it would be a very bizzare application and would probably need a redesign.
I hope this helps, if not feel free to link a follow up.
HIG states that the Show/Hide Clipboard menu item should be at the bottom of the Edit menu. My app contains a Window menu that lists all application windows (Ruler, Find/Replace, etc.) and all currently open document windows. It also has a menu item under the View menu called Show/Hide Ruler. What do you think about moving Show/Hide Clipboard and Show/Hide Ruler to our Window menu? The reason being that all of the window related commands (along with Tile and Stack Windows) would then be in one place (and under a logical heading, "Windows").
The classic reason for putting "Show Clipboard" in the Edit menu is that all things related to the clipboard are located there. This lets people find "Show Clipboard" by association. So much for the obvious stuff.
There's no reason why you can't put "Show Clipboard" in your Windows menu, as long as ALL of the app windows you bring up can be done from this window. You've said as much in your link, I'm just stressing the all part. I'd also be careful to somehow distinguish between an item that "opens" a window and one that "goes to" an already open one. Your window should be just that, a list of open windows. The list of commands to open windows(show clipboard, Show ruler, etc.) should be obviously separate from this list.
HIG states that when entering text into a "text" document, pressing Enter has no effect. We currently have a Go To Selection menu item (with command-key "G") but I prefer Think C's method of using the Enter key to toggle between the top and bottom of the current selection. The Enter key is a lot easier to hit than Command-G. How do you feel about that kind of functionality in the Enter key?
It sounds like you already have command-g for the functionality you want. I don't agree that "Enter" is easier than command-g; it may be easier for you, but not everyone.
If every app adds special functionality to a to a small "corner" of the interface that just happens to be unused, the benefits of consistency would be lost, you could never predict what that particular corner would do. As we aren't going to make your "Enter" behavior a standard across the Mac, you'll have a key that most folks won't discover. If they do, it won't work with any other apps which is frustrating.
I have heard rumors of an Apple sanctioned "Preferences Folder" in the System Folder as the standard place to put application preference files. Can you tell me anything about it?
The plan for System 7.0 includes a subfolder of the System Folder called "Preferences" The purpose of this folder is of course for apps to put their preferences files, so they don't clutter up the System Folder itself (since frequently people want to muck about with the contents of the System Folder, but only rarely do people want to muck about with their preferences files). The Preferences Folder (and the System Folder in general) are for non-shared files only--any thing that could be shared between multiple users, like a dictionary file, should not be kept in the System Folder but instead should be kept with/near the application.
The Preferences folder in 7.0 will have a hardwired name ("Preferences" on English-language systems) that's controlled by some new software called the Folder Manager. Apps will be able to make the appropriate calls to the Folder Manager to get back the right folder, so apps won't have to know the hardwired name (and at least for international reasons apps should not try to use the hardwired name).
The procedure for apps will be: look in Preferences. If your preference file isn't there, look in System Folder. If your preferences file isn't there either, create a new one in the Preferences Folder.
